温馨,樊婧雯,王富强.基于OpenResty平台的API网关系统的设计与实现[J].信息化研究,2020,46(03):62-68.
目录 Table of Contents
阅读本论文后，主要讨论以下两点：
- API 网关设计
- API 网关实现
API 网关设计
API网关软件
- 读多，实现安全认证、流量控制、请求重写、反向代理、负载均衡和结果缓存等功能。
API网关监控管理中心
- 写多，实现服务配置、日志管理、系统监控、API管理等功能。
注：为实现数据的读写分离，提高网关的性能，网关不进行数据处理操作，数据处理由监控管理中心负责。
持久层
- Redis：缓存配置和结果、分布式限流等
- MongoDB：存储核心层的数据
- MySQL：存储管理层和监控层的数据
- Zookeeper：服务发现与服务注册
注：由于作者对数据同步和消息订阅没有详细展开讨论，个人直观感觉设计得有点过复杂了。
本文的架构设计会涉及三次数据同步和消息订阅，一是 Zookeeper 和 MySQL 之间，二是 MySQL 和 MongoDB 之间，三是 MongoDB 和 Redis 之间。毕设的架构设计只涉及一次数据同步和消息订阅，即为 MySQL 和 Redis 之间。
- 引入 Zookeeper 实现服务注册与服务发现，不可简化；MySQL 和 MongoDB 之间可以二者选一，MySQL 提供很好的事务性支持，MongoDB 更快速和易用，两者备份都有较成熟的方案；Redis 需要用作缓存与限流，不可简化。
- Zookeeper 和 MySQL 之间可不同步，因为配置间有实体映射关系；MySQL 和 Redis 之间必须同步，以提高网关访问性能和实现配置热更新。
API 网关实现
流量控制
- 使用 Redis 作为全局的分布式计数器。
- 业务层面，设周期为
t和 阈值为d，则 TPS 为d/t；技术层面，Redis 创建一个存储访问的键，设置过期时间为t，当值达到d则触发自动告警或熔断降级。
服务兜底
- 与流量控制相结合，保证上游的数据服务永不消失。
- 两种实现方式：一是触发限流后请求重定向到
fallback过程中处理，可以主动发起二次请求获取兜底数据，这种做法需引入额外的回调逻辑，但数据和后端服务是保持一致的；二是从缓存中读取响应数据，这种做法不能保证数据一致，但是速度快且改动小。
总结
本文提出了一种基于 OpenResty 实现的微服务 API 网关的架构，在拆分服务、数据库的选型、数据同步和消息订阅这三个方面为毕设工作提供了宝贵的参考。
